ops/commands/restore-db.ts (1)

11-22: Consider handling stat errors in listBackups.

If a backup directory is deleted between readdirSync and statSync, an uncaught exception would be thrown. This is unlikely in practice for a CLI tool, but wrapping in try-catch would be more robust.

♻️ Optional: handle potential race

 function listBackups(): string[] {
   if (!fs.existsSync(DATA_DIR)) return []
   return fs
     .readdirSync(DATA_DIR)
-    .filter(
-      (f) =>
-        f.startsWith('backup_') &&
-        fs.statSync(path.join(DATA_DIR, f)).isDirectory(),
-    )
+    .filter((f) => {
+      if (!f.startsWith('backup_')) return false
+      try {
+        return fs.statSync(path.join(DATA_DIR, f)).isDirectory()
+      } catch {
+        return false
+      }
+    })
     .sort()
     .reverse()
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@ops/commands/restore-db.ts` around lines 11 - 22, The listBackups function
can throw if a file is removed between fs.readdirSync and fs.statSync; update
listBackups to catch errors around the fs.statSync (or use fs.lstatSync) when
checking each entry so a missing/removed entry is skipped instead of bubbling an
exception. In practice wrap the fs.statSync(path.join(DATA_DIR,
f)).isDirectory() check in a try-catch (inside the .filter callback), return
false on error, and keep the existing startsWith('backup_') logic so deleted
entries are ignored safely.

ops/commands/pull-db.ts (2)

60-71: Consider wrapping remote execution in try-catch for friendlier errors.

If the remote script fails (e.g., SSH connection drops, script error), execFileSync throws with a raw error. A try-catch with a user-friendly message would improve the CLI experience.

♻️ Optional: add error handling

   consola.start('Remote: checkpointing databases and creating archive...')
+  let output: string
+  try {
-  const output = execFileSync(
+    output = execFileSync(
       'fly',
       [
         'ssh',
         'console',
         '-a',
         app,
         '-C',
         'sh /upflow/ops/remote/prepare-pull.sh',
       ],
       { encoding: 'utf-8', stdio: ['pipe', 'pipe', 'pipe'] },
     )
+  } catch (err) {
+    consola.error('Failed to execute remote backup script')
+    consola.error(err instanceof Error ? err.message : String(err))
+    process.exit(1)
+  }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@ops/commands/pull-db.ts` around lines 60 - 71, Wrap the execFileSync call
that assigns output in pull-db.ts in a try-catch to handle thrown errors from
remote execution; catch the error from execFileSync, log a friendlier message
including contextual info (e.g., the app variable and that the remote
prepare-pull.sh failed) and the underlying error.message, and then rethrow or
exit with a non-zero code as appropriate so the CLI fails gracefully; reference
the execFileSync invocation and the output variable when adding the try-catch.

---

99-105: Tar extraction path traversal consideration.

The tar archive is created by the remote prepare-pull.sh using -C "$STAGING_DIR" ., which should produce relative paths. However, if the remote archive were compromised, it could contain paths like ../malicious. The extraction uses cwd: DATA_DIR without --strip-components or path validation.

Given this is an internal ops tool pulling from your own Fly app, this is low risk, but for defense-in-depth you could add safeguards.

🛡️ Optional: restrict extraction to DATA_DIR

   consola.start('Extracting archive...')
-  execFileSync('tar', ['xzf', path.resolve(localTar)], {
+  execFileSync('tar', ['xzf', path.resolve(localTar), '--no-absolute-names'], {
     cwd: DATA_DIR,
     stdio: 'inherit',
   })

ops/commands/pull-db.ts (1)

55-66: Consider capturing stderr for debugging remote failures.

With stdio: ['pipe', 'pipe', 'pipe'], stderr is piped but not captured by execFileSync (which only returns stdout). If the remote script outputs diagnostic messages to stderr before failing, they'll be lost.

♻️ Optional: capture stderr for better diagnostics

-  const output = execFileSync(
+  let output: string
+  try {
+    output = execFileSync(
     'fly',
     [
       'ssh',
       'console',
       '-a',
       app,
       '-C',
       'sh /upflow/ops/remote/prepare-pull.sh',
     ],
     { encoding: 'utf-8', stdio: ['pipe', 'pipe', 'pipe'] },
   )
+  } catch (err) {
+    if (err instanceof Error && 'stderr' in err) {
+      consola.error('Remote stderr:', (err as { stderr: string }).stderr)
+    }
+    throw err
+  }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@ops/commands/pull-db.ts` around lines 55 - 66, The execFileSync call that
assigns to output currently loses stderr because execFileSync only returns
stdout; to preserve remote diagnostic messages, wrap the execFileSync(...) call
in a try/catch and, on error, read and surface the error.stderr (and
error.stdout) properties (or change to spawnSync and capture both stdout/stderr)
so you can log or include stderr in your failure message; update the code around
the const output = execFileSync(...) invocation to catch the thrown Error from
execFileSync and log/return error.stderr for debugging.